YARN

[Hadoop] 分布式资源调度YARN 四

生产如何调优Container参数(container内存、container虚拟核、官方建议、综合memory+vcore、默认规则、假如该节点还有组件)、Yarn调度器和调度算法(FIFO调度器、Capacity Scheduler资源调度器、Fair Scheduler资源调度器)

Posted by 李玉坤 on 2017-07-17


假设我们有一台物理机器 128G内存 16个core

生产如何调优Container参数？

Container：虚拟化的容器 维度 memory+vcore
作用是运行task任务

  • 装完CentOS，消耗内存1G
  • 系统预览15%-20%内存(包含系统1G内存)，
    以防全部使用导致系统夯住 和 oom机制事件，或者给未来部署组件预览点空间
  • 此时需要预留内存为：128*20%=25.6G == 预留 26G
  • 假设只有DN NM节点，余下内存 128-26=102g
  • DN=2G、NM=4G；所以剩下102-2-4=96G

container内存

  • 可以调优如下：
    • yarn.nodemanager.resource.memory-mb 96G
    • yarn.scheduler.minimum-allocation-mb 1G 极限情况下，只有96个container 内存1G
    • yarn.scheduler.maximum-allocation-mb 96G 极限情况下，只有1个container 内存96G
  • container的内存会自动增加，默认1g递增
    每个container内存范围:1-96个

container虚拟核

  • vcore
    yarn自己引入的，设计初衷是考虑不同节点的CPU的性能不一样，每个CPU的计算能力不一样。
    比如某个物理CPU是另外一个物理CPU的2倍，这时通过设置第一个物理CPU的虚拟core来弥补这种差异。

  • 十年之前：

    • 第一台机器 强悍 pcore: vcore=1:2
    • 第二台机器 不强悍 pcore: vcore=1:1
    • 在xml配置

  • 官网默认 yarn.nodemanager.resource.pcores-vcores-multiplier 2

  • 目前已无需调整这个参数，因为现在的物理机性能都差不多
    所有节点 pcore: vcore=1:2

  • 物理核:虚拟核 =1:2 此时这台机器有32个vcore

  • 可以调优如下：

    • yarn.nodemanager.resource.cpu-vcores 32
    • yarn.scheduler.minimum-allocation-vcores 1 极限情况下，只有32个container
    • yarn.scheduler.maximum-allocation-vcores 32 极限情况下，只有1个container
    • container个数范围为:1-32个

官方建议

  • cloudera公司推荐，一个container的vcore最好不要超过5，那么我们设置4
  • yarn.scheduler.maximum-allocation-vcores 4 极限情况下，只有8个container

综合memory+vcore

  • 首先可以确定 vcore=4 container 8个
  • 确定内存：
    • yarn.nodemanager.resource.memory-mb 96G
    • yarn.scheduler.minimum-allocation-mb 1G
    • yarn.scheduler.maximum-allocation-mb 12G 极限container 8个
  • 确定vcore
    • yarn.nodemanager.resource.cpu-vcores 32
    • yarn.scheduler.minimum-allocation-vcores 1
    • yarn.scheduler.maximum-allocation-vcores 4 极限container 8个
  • 8个container 12G 4vcore

当然当spark计算时内存不够大，这个参数肯定要调大，那么这种理想化的设置个数必然要打破，以memory为主，也就是说可以舍弃部分vcore（也就是调整vcore的个数来改变container的个数）。

默认规则

如果不合理规划，按照官网默认参数

  • 内存
    • yarn.nodemanager.resource.memory-mb 96G
    • yarn.scheduler.minimum-allocation-mb 1G
    • yarn.scheduler.maximum-allocation-mb 8G
    • 12container 12*2=24 浪费了36-24=12个core
  • vcore
    • yarn.nodemanager.resource.cpu-vcores 32
    • yarn.scheduler.minimum-allocation-vcores 1
    • yarn.scheduler.maximum-allocation-vcores 2
    • 16 container*8g 内存爆掉

假如该节点还有组件

假如 256G内存 56core，并且有hbase regionserver进程，那么该如何设置？
hbase regionserver = 30G

256*20%=52

256-2-4-30-52=168

56/4=14

  • 首先可以确定 vcore=4 container 14个
  • 确定内存：
    • yarn.nodemanager.resource.memory-mb 168G
    • yarn.scheduler.minimum-allocation-mb 1G
    • yarn.scheduler.maximum-allocation-mb 12 G 极限container 14个
  • 确定vcore
    • yarn.nodemanager.resource.cpu-vcores 56
    • yarn.scheduler.minimum-allocation-vcores 1
    • yarn.scheduler.maximum-allocation-vcores 4 极限container 14个
  • 14个container 12G 4vcore

Yarn调度器和调度算法

  • 集群资源调度器需要解决：
    • 多租户(Multi-tenancy)：
      • 多用户同时提交多种应用程序
      • 资源调度器需要解决如何合理分配资源。
    • 可扩展性(Scalability)：增加集群机器的数量可以提高整体集群性能。
  • Yarn使用队列解决多租户中共享资源的问题

  • 支持三种资源调度器
    • FIFO
    • Capacity Scheduler
    • Fair Scheduler

  1. FIFO 先进先出
  • 意思就是队列需要等待，如图中job2必须在job1执行完毕之后才可以执行
  1. Capacity 计算
  • 官网 https://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html
  • 有一个专门的队列来运行小任务，但是为了小任务专门设置一个队列预先占用一定的集群资源。
  • 这会导致大任务的执行时间落后FIFO的调度时间
  • 如图中有一个常置队列B，小作业job2会直接进入queueB和job1同时进行计算
  • 如果有大作业过来，就会和FIFO一样需要等待queueA中的job执行结束才可以进行
  1. Fair 公平

apache 默认计算:
yarn.resourcemanager.scheduler.class
org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler

CDH 默认公平:
web配置 Fair

FIFO调度器

  • 所有向集群提交的作业使用一个队列
  • 根据提交作业的顺序来运行（先来先服务）
  • 优点：
    • 简单易懂
    • 可以按照作业优先级调度
  • 缺点：
    • 资源利用率不高
    • 不允许抢占

Capacity Scheduler资源调度器

  • 设计思想：
    • 资源按照比例分配给各个队列

  • 特点
    • 计算能力保证
      • 以队列为单位划分资源，每个队列最低资源保证。
    • 灵活性
      • 当某个队列空闲时，其资源可以分配给其他的队列使用。
    • 支持优先级
      • 单个队列内部使用FIFO，支持作业优先级调度
    • 多租户
      • 综合考虑多种因素防止单个作业、用户或者队列独占资源。
      • 每个队列可以配置一定比例的最低资源配置和使用上限。
      • 每个队列有严格的访问控制，只能向自己的队列提交任务。
    • 基于资源的调度
      • 支持内存资源调度和CPU资源的调度。
    • 支持抢占（从2.8.0版本开始）

Capacity Scheduler配置

Capacity Scheduler资源分配算法

  1. 选择队列
    • 从根队列开始，使用深度优先算法找出资源占用率最低的叶子队列
  2. 选择作业
    • 默认按照作业优先级和提交时间顺序选择
  3. 选择Container
    • 取该作业中最高优先级的Container，如果优先级相同会选择满足本地性的Container：Node Local >Rack Local > Different Rack

Fair Scheduler资源调度器

  • 设计思想
    • 资源公平分配
  • 具有与Capacity Scheduler相似的特点
    • 树状队列
    • 每个队列有独立的最小资源保证
    • 空闲时可以分配资源给其他队列使用
    • 支持内存资源调度和CPU资源调度
    • 支持抢占
  • 不同点
    • 核心调度策略不同
      • Capacity Scheduler优先选择资源利用率低的队列
      • 公平调度器考虑的是公平，公平体现在作业对资源的缺额
    • 单独设置队列间资源分配方式
      • FAIR（默认used memory/min share）
      • DRF（主资源公平调度）
    • 单独设置队列内部资源分配方式
      • FAIR DRF FIFO

FAIR资源分配算法

  • 总体流程与Capacity Scheduler一致
    • 1.选择队列
    • 2.选择作业
    • 3.选择Container
  • 选择队列和作业使用公平排序算法
    • 实际最小份额
      minShare = Min(资源需求量，配置minShare）
    • 是否饥饿
      isNeedy = 资源使用量< minShare
    • 资源分配比
      minShareRatio = 资源使用量/Max(minShare, 1)
    • 资源使用权重比
      useToWeightRatio = 资源使用量/权重
      权重在配置文件中配置
  • 参考 FairShareComparator实现类

Capacity Scheduler和Fair Scheduler对比




FEATURED TAGS
YARN